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Abstract. We briefly present a rule-based framework, called Eagle, that has 
been shown to be capable of defining and implementing finite trace monitoring 
logics, including future and past time temporal logic, extended regular expres- 
sions, real-time logics, interval logics, forms of quantified temporal logics, and 
so on. In this paper we show how EAGLE can do linear temporal logic (LTL) 
monitoring in an efficient way. We give an upper bound on the space and time 
complexity of this monitoring. 


1 Introduction 

Runtime verification, or runtime monitoring, comprises having a software module, an 
observer, monitor the execution of a program, and check its conformity with a require- 
ment specification, often w ritten in a temporal logic or as a state machine. Runtime 
verification can be applied to evaluate automatically test runs, either on-line or off-line, 
analyzing stored execution traces; or it can' be used on-line during operation, potentially 
steering the application back to a safety region if a property is violated. It is highly scal- 
able. Several runtime verification systems have been developed, of which some were 
presented at three recent international workshops on runtime verification [1]. 

Linear temporal logic (LTL) [17] has been core to several of these attempts. The 
commercial tool Temporal Rover (TR) [5, 6] supports a fixed future and past time LTL, 
with the possibility of specifying real-time and data constraints (time-series) as anno- 
tations on the temporal operators. Its implementation is based on alternating automata. 
Algorithms using alternating automata to monitor LTL properties are also proposed in 
[8], and a specialized LTL collecting statistics along the execution trace is described 
in [7]. The MAC logic [16] is a form of past- time LTL with operators inspired by in- . 
terval logics and which models real-time via explicit clock variables. A logic based on 
extended regular expressions [18] has also been proposed and is argued to be more suc- 
cinct for certain properties. The logic described in [14] is a sophisticated interval logic, 
argued to be more user-friendly than plain LTL. Our own previous work includes the de- 
velopment of several algorithms, such as generating dynamic programming algorithms 
for past time logic [12], using a rewriting system for monitoring future-time logic [11], 
or generating Biichi automata inspired algorithms adapted to finite trace LTL [10]. 
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This large variety of logics prompted us to search for a small and general framework 
for defining monitoring logics, which would be powerful enough to capture essentially 
all of the above described logics, hence supporting future and past time logics, interval 
logics, extended regular expressions, state machines, real-time and data constraints, and 
statistics. The framework should support the definition of new logics in an easy manner 
and should support the monitoring of programs with their complex program states. The 
result of our search is the logic Eagle which is described in details in [4], In this paper 
we briefly describe EAGLE and its expressivity and then focus mainly on the subset 
LTL and analyze it complexity. The Eagle logic and its implementation for run-time 
monitoring has in particular been significantly influenced by earlier work of Barringer 
et al., see for example [3], on the executable temporal logic MetateM. A linear-time 
temporal formula can be separated [9] into a boolean combination of pure past, present 
and pure future time formulas - in particular, the combination can be written as a collec- 
tion of “directly executable” global conditional rules of the form “if pure past-time then 
present-time and pure future-time”. The present-time, or state, formulas determine how 
the state for the current moment in time is built and the pure future-time formulas yield 
obligations that need to be fulfilled at some time later. The separation result, rules and 
future obligations are central in our current work. However, the fundamental difference 
between MetateM and EAGLE is that the MetateM interpreter builds traces state by 
state, whereas Eagle is used for checking given finite traces: costly implementation 
features, such as backtracking and loop-checking, are not required. 

We recently discovered parallel work [15] using recursive equations to implement 
a real-time logic. However we had already developed the ideas further. We provide the 
language of recursive equations to the user, we support a mixture of future time and 
past time operators, we treat real-time as a special case of data values, and hence we 
allow a very general logic for reasoning about data, including the possibility of relating 
data values across the execution trace, both forwards and backwards. 

'. The paper is structured as follows. Section 2 introduces our logic framework, then 
in section 3 we discuss the algorithm and calculus that underlies our implementation 
for the special case of LTL, which is then briefly described along with complexity and 
initial experimentation in section 4. 

2 The Logie 

In this section we briefly describe the temporal finite trace monitoring logic EAGLE[4], 
The logic offers a succinct but powerful set of primitives, essentially supporting re- 
cursive parameterized equations, with a minimal/maximal fix-point semantics together 
-with-tIireii-temporal-Qp<SFat 0 rs-.-next-time 1 -previou.s-time^and.concatenation.-The-next- 
time and previous-time operators can be used for defining future time respectively past 
time temporal logics on top of EAGLE. The concatenation operator can be used to define 
interval logics and an extended regular expression language. Rules are parameterized 
to allow for reasoning about data values, including real-time. Atomic propositions are 
boolean expressions over a program state, Java states in the current implementation. 
The logic is first introduced informally through two examples whereafter its syntax and 
semantics is given. Finally, its relationship to some other important logics is outlined. 
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2.1 EAGLE by Example 

Fundamental Concepts Assume we want to state a property about a program P, which 
contains the declaration of two integer variables x and y. We want to state that whenever 
x is positive then eventually y becomes positive. The property can be written as follows 
in classical future time LTL: d(x > 0 — * Oy > 0)- The formulas OF (always F ) and 0 F 
(eventually F), for some property F, usually satisfy the following equivalences, where 
the temporal operator QF stands for next F (meaning ‘in next state F’): 

□f = faoP0 of = fvq>(<)F) 

One can show that QF is a solution to the recursive equation X = F A 0-^1 in fact 
it is the maximal solution. A fundamental idea in our logic is to support this kind of 
recursive definition, and to enable users define their own temporal combinators using 
equations similar to those above. In the current framework one can write the following 
definitions for the two combinators Always and Eventually, and the formula to be 
monitored (Mi): 

max Always (Form F) =F A0&lvays(F) 

min Eventuallvl Form F) = F V 0 Ev entuall y(F) 

mon Mi = Always(x > 0 — * £ventually(y > 0)) 

The Always operator is defined as a maximal fix-point operator; the Eventually oper- 
ator is defined as a minimal fix-point operator. Maximal rules define safety properties 
(nothing bad ever happens), while minimal rules define liveness properties (something 
good eventually happens). For us, the difference only becomes important when eval- 
uating formulas at the boundaries of a trace. To understand how this works it suffices 
to say here that monitored rules evolve as new states are appearing. Assume that the 
end of the trace has been reached (we are beyond the last state) and a monitored for- 
mula F has evolved to F'. Then all applications in F' of maximal fix-point rules will 
evaluate to true, since they represent safety properties that apparently have been satis- 
fied throughout the trace, while applications of minimal fix-point rules will evaluate to 
false, indicating that some event did not happen. Assume for example that we evaluate 
the formula Mi in a state where x > 0 and y < 0, then as a liveness obligation for the 
future we will have the expression: 

OEventu'ally(y > 0) A 0 A lways(x > 0 — * Eventually(y > 0)) 

Assume that we at this point detect the end of the trace; that is: we are beyond the last 
state. The outstanding liveness obligation Eventually(y > 0) has not yet been fulfilled, 
which is an error. This is captured by the evaluation of the minimal fix-point combinator 
Eventually to false at this point. The remaining other obligation from the A-formula, 
namely, Always(x > 0 — » Eventually^ > 0)), is a safety property and evaluates to 
true. 

For completeness we provide remaining definitions of the future time LTL operators 
U (until) and W (unless) below. Note how W is defined in terms of other operators. 
However, it could have been defined recursively, 

min Until ( Form Fi , Form F?) =Fi V(Fj AQDntil(Fi,F 2 )) 
max Unless (Form F; . Form F?) = Until(F 1 ,F 2 ) V Always (Fi) 
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Data Parameters We have seen how rules can be parameterized with formulas. Let’s 
complicate the example with data parameters. Suppose we want to state the property: 

"whenever at some point k = x > 0 for some k, then eventually y == k” . This can 
be- stated as follows in quantified LTL: □(* > 0 — + 3 k.{k — x A Oy — k)). We use pa- 
rameterized rules to state this property, capturing the value of x when x > 0 as a rule 
parameter. 

min Pfjnt k) = Eventually(s.y == k) mon Mr = Alwaysl'.f.x > 0 —>■ Rjs.x )) 

Rule R is parameterized with an integer k, and is instantiated in M 2 when x > 0, hence 
capturing the value of x at that moment. Rule R replaces the existential quantifier. The 
logic also provides a previous-time operator, which allows us to define past time op- 
erators; the data parametrization works uniformly for rules over past as well as future, 
which is non-trivial to achieve since the implementation does not store the trace, see 
Section 4. Data parametrization is also used to elegantly model real-time logics. 

2.2 Syntax and Semantics 

Syntax A specification S consists of a declaration part D and an observer part O. D 
consists of zero or more rule definitions R, and O consists of zero or more monitor 
definitions M, which specify what to be monitored. Rules and monitors are named (AO- 

S' ::= dec D obs O 
D ::= R* 

0 ::= M* 

R ::= ( max | min } N(T\ x\ T„x„) ~F 

M::=N = F 

T Form | java primitive type 

F java expression | true | false | -*F | F\ AF 2 | F\ VF 2 j F\ — ► ft | 

QF | OF | F 1 /F 2 | N(Fi,:..,F n ) 

A rule definition R is preceded by a keyword indicating whether the interpretation is | 

maximal or minimal (which we recall determines the value of a rule application at the 
boundaries of the trace). Parameters are typed, and can either be a formula of type Form , 

or of a primitive Java type, such as int, long, float , etc.. The body of a rule/monitor is j 

a formula of the syntactic category Form (with meta-variables F, etc.). The proposi- S 

tions of this logic are Java expressions over an observer state. These can be arbitrary | 

Java expressions using all of Java’s expression language constructs, recommended not I 

to have no side effects. Formulas are composed using standard propositional logic op- | 

crators together with a next-state operator (Q F), a previous-state operator (O F), and a | 

concatenation-operator (F\ ■ F%). Finally, rules can be applied and their parameters must ' f 

be type correct; formula arguments can be any formula, with the exception that if an g 

argument is a java expression, it must be of boolean type. 

Semantics The semantics of the. logic is defined in terms of a satisfaction relation 
(= C Trace x Form between execution traces and specifications. An execution trace cr 
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is a finite sequence of program states a = sis 2 ...s n , where jaj = n is the length of the 
trace. The i’th state s, of a trace a is denoted by c(i). The term denotes the sub- 
trace of 0 from position i to position j, both positions included. In the implementation a 
state is a user defined Java object that is updated through a user provided update method 
for each new event generated by the program. Given a trace 0 and a specification dec D 
obs O, satisfaction is defined as follows: 

a (= dec D obs O iff W (N = F) £ O . a,\ j=o F 

That is, a trace satisfies a specification if the trace, observed from position 1 (the first 
state), satisfies each monitored formula. The definition of the satisfaction relation \=D 
C ( Trace x nat) x Form, for a set of rule definitions D, is presented below, where 
0 < i < n + 1 for some trace ct — rir 2 • • -s n . Note that the position of a trace can become 
0 (before the first state) when going backwards, and can become n+l (after the last 
state) when going forwards, both cases causing rule applications to evaluate to either 
true if maximal or false if minimal, without considering the body of the rules at that 
point. 


o,i\= D jexp 
a, i \=d true 
o, i false 
a,i J=o ->F 
a,i |=o Fi A F 2 
0, i f =d F\ V F 2 
i f=o F i ->F 2 
cM l=o OF 
<V |=o QF 
c, i ho F\ ■ F 2 


a,i\= D N(F u ...,F m ) 


iff 1 < i < jcr| and evaluate(jexp)(a(i )) == true 


iff a, i Y=d F 

iff o, i j =d Fi and cr, i \= D F 2 

iff cr, i \= D Fi or o, i (=o F 2 

iff c, i | =d F\ implies a, i f=£> F 2 

iff i < j a| and cr, i+ 1 (=o F 

iff 1 < i and a, i — 1 f=0 F 

iff 3 j> i s.t. ho F\ and othl°l], i \^ D p 2 


iff 


if 1 < i < jaj then: 

cr, i ho F[xi Fi , . . . ,x n >-* F n ] 
where (N(T\X\,...,T n x n ) =F) &D 
otherwise, if i = 0 or i = |oj + 1 then: 


[ rule N is defined as max in D 


A Java expression (a proposition) is evaluated in the current state in case the position i is 
within the trace (1 < / < n). In the boundary cases (i = 0 and i = n + l) Java expressions 
evaluate to false. Propositional operators have their standard semantics in all positions. 
A next-time formula O F evaluates to true if the current position is not beyond the 
last state and F holds in the next position. Dually for the previous-time formula. This 
means that these formulas always evaluate to false in the boundary positions (0 and 
n + 1). The concatenation formula F\ ■ F 2 is true if the trace a can be split into two sub- 
traces a = 0102 , such that F\ is true on O;, observed from the current position i, and 
F 2 is true on 02 (ignoring 01 , and thereby limiting the scope of past time operators). 
Applying a rule within the trace (positions 1 ...n) consists of replacing the call with the 
right-hand side of the definition, substituting arguments for formal parameters. At the 
boundaries (0 and n - f 1) a rule application evaluates to true if and only if it is maximal. 
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2.3 Linear Temporal Logic in Eagle 

In this section we define the different operators for LTL in the form of rules. For the 
special case of Eagle, one writes an LTL formula to be monitored using these opera- 
tors only. We do not allow to define new operators in the form of rules, as our algorithm 
is hardwired with these operators and we do not do any synthesis of monitor for this 
special case, LTL. However, in general EAGLE, one can define new temporal operators 
as rules and in that case we synthesize the monitors. 


Future Time LTL We start with the standard future time linear temporal, logic based 
on the temporal modalities, O and U ■ We also define the other modalities, such as 
□, 0 and ‘W , directly as rules in EAGLE. Our embedding relies upon the fact that the 
formula (j) U \j/ corresponds to the minimal solution to the equation X = \|/ V <j> A O-^- 

max Always (Form F) = F A O^-lway s (F)) 

min Eventuallvl Form F) = FV 0 Eventually(F)) 

min Until fForm Fi . Form F>.) = F2 V {F\ AO Unt ^l(^U^2)) 

max Un less ( Form Fi. Form F?) =i*2 V (Fl AOUnless(Fi,F2)) 

Note that the unless modality is defined as maximal since we require that 
Unless(Fi,/^) evaluates to true on the empty sequence, unlike Until (Fi,!^) that must 
evaluate to false on the empty sequence. 


Past Time LTL: A past time linear temporal logic, i.e. one whose temporal modalities 
only look to the past, could be defined in the mirror way to the future time logic by using 
the built-in previous modality, ©, in place of the future next time modality, Q. We 
define an explicit rule, Previous, for the © modality in Past Time LTL. This is done for 
technical reason (becomes clear later) and we assume that in an LTL formula one uses 
Previous instead of Q. Note that the Zince rule defines the past-time correspondent 
to the future time unless, or weak until, modality, i.e. it is a weak version of Since. 

min Previous ( Form F) = OF 

max Alway slnP as t ( Form F) = F A 0 Always InPast (F)) 
min EventuallyInPast(Fonn F) = F V 0 EventuallyInPast(F)) 
min Since (Form F; , Form F>) =F2 'V(Fi A©Since(Fi,F2)) 
max Zince (Form Fi , Form F>) = F2 V (Fy AQZince(Fi,F2)) 

Combined Future and Past Time LTL: By combining the definitions for the future 
and past time LTLs defined above, we obtain a temporal logic over the future, present 
and past, in which one can freely intermix the future and past time modalities (to any 
depth). 

2.4 Relationship to Other Logics 

Although in this paper we use Eagle for LTL monitoring, in general Eagle is expres- 
sively rich; indeed, any linear-time temporal logic, whose temporal modalities can be 
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recursively defined over the next, past or concatenation modalities, can be embedded 
within it. Furthermore, since in effect we have a limited form of quantification over 
possibly infinite data sets, and concatenation, we are strictly more expressive than, say, 
a linear temporal fixed point logic (over next and previous). A formal characterization 
of the logic is beyond the scope of this paper, however to make the paper self-contained, 
we demonstrate the logic’s utility and expressiveness through some examples. However, 
if the readers interested on LTL monitoring can skip this subsection. 


Combined Future and Past Time LTL with Data Values: We are thus able to express 
constraints such as if ever the variable x exceeds 0, there was an earlier moment when 
the variable y was 4 and then remains with that value until it gets increased sometime 
later, possibly after the moment when x exceeds 0. 

mon M 2 — Always(x > 0 — ► EventuallyInPast(y == 4 AUntil(y —=4,y > 4))) 


Extended LTL and juTL: The ability to define temporal modalities recursively pro- 
vides the ability to define Wolper’s ETL or the semantically equivalent fixpoint temporal 
calculus. Such expressiveness is required to capture regular properties such as temporal 
formula F is required to be true on every even moment of time: 

max Even (Form F) = F A O O Even(F) 

The fjT L formula vx.p AQQxA py.q A Qx VQy, where p and q are atomic formulas, 
would be denoted by the formula, X(), where rules X and Y are: 

maxX() =pAOOX()AY() nun Y() = q AQxQV Qy() 

Extended Regular Expressions: The language of Extended Regular Expressions 
(ERE), i.e. adding complementation to regular expressions, has been proposed as a 
powerful formalism for run-time monitoring. ERE can straightforwardly be embedded 
within our rule-based system. Given, E ::= <b\z\a\E -E\E + E\EC\E\^E\E*, let Tr(E') 
denote the ERE E's corresponding Eagle formula. For convenience, we define the 
rule max Empty () = -iQ true which is true only when evaluated on an empty (suffix) 
sequence. Tr is inductively defined as follows. 

T!r(0) = false Tr(s) = Empty() 

Tr (a) =aAOEmpty() Tr(E 1 -E 2 ) =Tr(Ei)-Tr(E 2 ) 

TV (Ei + E 2 ) = Tr(2?i ) V Tr(E 2 ) Tr (E x n E 2 ) = Tr (£j ) A Tr(£ 2 ) 

Tr(-iE) = -iTr(E) 

Tr(£*) -X() where max X() = Empty 0 ) (Tr (E)-XQ) 


Real Time as a Special Case of Data Binding: Metric temporal logics, in which 
temporal modalities are parameterized by some underlying real-time clock(s), can be 
straightforwardly embedded into our system through rule parameterization. For exam- 
ple, consider the metric temporal modality, of' 1 ’' 2 ) in a system with just one global clock. 
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the formula true if and only if (!) holds at some 
time in the future when the real-time clock has value within the interval [i\,t2]. For our 
context, we assume that the finite sequence of states being monitored contains a variable 
clock giving the real-time value of the clock for the associated state. The rule 


min EventAbsf Form F, long t \ , long £2) = 

clock <=t2 A (F — + ti <— clock) A (-1F — ► OEventAbs(F,fi,f2)) 


defines the operator for absolute values of the clock. A relativized version of the 
modality can then be defined as: 

min EventRelf Form F, long t \ , long tj) = Event Abs (F, clock + 1 \ , clock + ti)) 


Counting and Statistical Calculations: In a monitoring context, one may wish to 
gather statistics on the truth of some property, for example whether a particular state 
property <j> holds with at least some probability p over a given sequence, i.e. it doesn’t 
fail with probability greater than (1 — p). Consider the operator D p ty defined by: 


a, i j= O r tf> iff dS C {i..joj} s.t. 


Isl 

1 ~ >pA V; S S .' o,j f= ^ 

!cr| — z 


An encoding within our logic can then be given as: 


min Af Form d>, float print f, int t) = 

(QEmpty()A((ij>A(l-f) >= p) V H> A (1 - &±) >=p))) V 
(-■Empty () A ((<j> -4 1 )) A H> -> (>(<)>, p,/+ V + 1 )))) 

min Atheastf Form (j), float p) —A(<p,p, 0 , 1) 

Towards Context Free: Above we showed that Eagle could encode logics such as 
ETL, which extend LTL with regular grammars (when restricted to finite traces), or 
even extended regular expressions. In fact, we can go beyond regularity into the world 
of context-free languages, necessary, for example, to express properties such as every 
login is matched by a logout and at no point are there more logouts than logins. Indeed, 
such a property can be expressed in several ways in Eagle. Assume we are monitoring 
a sequence of login and logout events. We can define a rule Matchf Form Fi , Form F2) 
and monitor with Match (login, logout) where: 

min Matchf Form Ft, Form F?) = Fi -MatchfFi ,F>.) -F? • MatchfFi ,F?) V Empty() 

Less elegantly, and which we leave as an exercise, one could use the rule parametriza- 
tion mechanism to count the numbers of logins and logouts. 

3 Algorithm 

In this section, we now outline the computation mechanism used to determine whether a 
given monitoring formula given in LTL holds for some given input sequence of events. 
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On the observer side a local state is maintained. The atomic propositions are specified 
with respect to the variables in this local state. At every event the observer modifies 
the local state of the observer based on that event and then evaluates the monitored 
formulas on that state and generates a new set of monitored formulas. At the end of the 
trace the value of the monitored formulas are determined. The evaluation of a formula 
F on a state s — a(i) in a trace a results in an another formula eval(F,s ) with the 
property that c, i |= F if and only if <y,i + 1 \= eval(F,s). The definition of the operator 
eval : Form x State — *■ Form uses another auxiliary operator update : Form x State —> 
Form. The intuition behind using the operator update is to update a formula properly in 
presence of previous operators. The value of a formula F at the end of a trace is given ’ 
by value(F). The operator value : Form —> ( true , false ) returns true if the formula is 
satisfied by an empty trace and returns false otherwise. Thus given a sequence of states 
S1S2 ■ ■ ■ s„, an LTL formula F written in Eagle is said to be satisfied by the sequence 
of states if and only if value(eval(... eval(eval(F,sx),s 2 ) ■ ..s n )) is true . The definition 
of the operators eval, update and value forms the calculus of the recursive rule-based 
framework. We define this calculus next. 

3.1 Calculus 

The eval, update and value operators are defined a priori for all operators. Note that, 
unlike in general Eagle where new temporal operators in the form of roles can be 
defined, in LTL the operators are fixed. So instead of giving a general algorithm to 
synthesize the definitions of eval, update and value for the rules [ 4 ], we can synthesize 
these definitions for the fixed operators of LTL before hand and make them part of our 
calculus. We do not define the functions on the previous operator, since this operator is 
eliminated in the the calculus that we present next. The definition of eval, update and 
value on the different operators is given below. 

evalijexp, s ) = value of jexp in s 

eval[F\ op F 2 ,s) = eval(Fi,s) op eval(F 2 ,s) where op € {A,V,— *■} 
evalQF,s) = -1 eval(F,s ) 
eval(Q)F,s) = update(F,s) 

update (jexp, s ) = jexp 

update(F\ op F 2 ,s) = update(F\,s) op update(F 2 ,s ) where op G (A, V,— *} 
update (~>F,s) — ~^update(F,s) 

update (QF, s) = Qupdate(F,s) 

value (jexp) = false 

value(F\ op F 2 ) — value(F\ ) op value(F 2 ) where op £ {A, V,— >} 
valueQF) = ->value(F) 
value(QF ) = false 

Note that eval of a formula of the form QF on a state s reduces to the update of F on 
state s. This ensures that if F contains any past time operators then update of F updates 
them properly. Moreover, value((QF) is false as the operator Q) is assumed to have 
strong interpretation in the logic. The value of a max rule is true and that of a min rule 
is false . 

value( RfFi Fj)) — true if R is max 

value(R(Fi ,...,F n )) = false if R is min 
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However, the definition of the eval and update operators for the rules are not generic for 
all LTL operators. They are synthesized according to the definition of the rules in the 
specification and made part of the calculus. Consider the Always operator. 

max Alwavsf Form F) —F A 0 A l wa ys(F) 

For this rule eval and update are defined as follows. 

eval(Always(F),s) = eval(F AQklways(F),s) 
update(klways(F),s) = update(F A Q) Always (F),s) 

However, the definition of update results in infinite recursion. To break the recursion we 
note that the rule Always does not contain any previous operator, although the argument 
F may contain some. So we simply propagate the update to the argument F. Thus the 
new definition of update becomes: 

update (Always (F) , s) = Always (update(F,s)) 

In a similar way we can give the calculus for the other future time LTL operators as 
follows: 

evaI(Eventually(F),s) — eval(F VO Ev entually(F),j) 
update(Eventually(F), s) = Eventually (update(F,s)) 

eva/(Dntil(Fi,f 7 2),j) = eva/fTy V(Fi AQUrLtil(Fi,F2)) > s) 
update (Until(F), s) = Until(update(F} , s), update (F2 , s)) 

eval(Vnless(F\,F2),s) = eval(F2 V (Fi AOD n l e ss(fi,f2)),j) 
update(’Jnless(F),s) = Unless (update (Fi,s), update (F2,s)) 

However, the definitions are different for past time LTL operators. These operators de- 
fined in the form of rules contain previous operator. In general, if a rule contains a 
formula F guarded by a previous operator on its right hand side then we evaluate F at 
every event and use the result of this evaluation in the next state. Thus, the result of eval- 
uating F is required to be stored in some temporary placeholder so that it can be used 
in the next state. To allocate a placeholder, we introduce, for every formula guarded by 
a previous operator, an argument in the rule and use these arguments in the definition 
of eval and update for this rule. Let us illustrate this with the following example. 

max AlwaysInPastf Form F) = F AO Always InPast fF)) 

For this rule we introduce another auxiliary rule AlwaysInPast , which contains an 
extra argument corresponding to the formula 0 (AlwaysInPast(F)). 

. AlwaysInPastf Form F) = AlwaysInPastVF. true - ) 
evaI(AlwaysInPast / (F,p(Mr 1 ), s) = eval(F A pastes) 
update(Alwd.ysIn£ast'(F,past 1 ),s) = 

Always InPast' (update(F, s), eval(Al ways InPast 7 (F,past{), s)) 
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Here, in eval, the subformula Q(AlwaysInPast(F)) guarded by the previous operator 
is replaced by the argument pasi x that contains the evaluation of the subformula in the 
previous state. In update we not only update the argument F but also evaluate the sub- 
formula AlwaysInPast^Fj/mrJ and pass it as second argument of AlwaysInPast'. 

Thus in the next state past 1 is bound to 0(AlwaysInPast / (F,paJt 1 )). Note that in the 
definition of AlwaysInPast' we pass true as the second argument. This is because, 

AlwaysInPast being defined a maximal operator, its previous value at the beginning of 
the trace is true . 

In a similar way we can give the calculus for the other past time LTL operators as 
follows: 

Previous fForm F) = Previous'(F, false) 
eva/(Previous / (F,/Jarr 1 ), j) = eval(past u s ) 

update(?revious , (F,pasti),s) = Erevious\update(F,s),eval('9Tevious , (F,past l ) > s)) 

EventuallylnPastf Form F) = EventuallvInPast'fF, false ) 
eva/(EventuallyInPast'(F,/7(3i , r ] ), s ) = eval{F V past { , s ) 
update{EventuallylnE ast' {F,past{) ,s) = 

Eventually InE ast' (update^ F, rl , evuI(EvsntuaIlyInPsst'( F y pcist ~ L ) , s)) 

Sincef Form Fi . Form F?) = Since'fFi ,F>. false) 
eval(5ince'(F l ,F 2 ,past 1 ),s) = eval(F 2 V (Fi A pastes) 
update(Since / (Fi,F 2l past 1 ),s) = 

Since'(update(Fi,s),update(Fi,s),eval(Since , (Fi,F 2 ,past l ),s)) 

Zincef Form Fi . Form F>) — Zince'fFi ,F>, true ) 
eval(zince'(Fi t F 2 ,past 1 ),s) — eval(F 2 V (F\ Apast x ,s) 
update(Zince'(Fi,F 2 ,past l ),s) = 

Zince' (update(Fi , s ) ,-update{F\ , r) , evn/(Zince'(Fi , F 2l past l ),s)) 

For the sake of completeness of the calculus we explicitly define value on the above 
LTL operators as follows: 

va/we(Always(F)) = true vn/«e(Eventually(F)) = false 

value(J]niil(F\ ,F?)) = false vnhrgfUnlessfFi ,F 2 )) = true 
vaZ«e(AiwaysInPast(F)) = true vtf/n<?(EventuallyinPast(F)) = false 
value ( Since (Fi ,F?.)) = false value(z±nce(Fi ,F>)) = tme 

i 

ii 
i 

it 

i 

' 

I 


Note that in the above calculus we have got rid of the previous operator by introducing 
an auxiliary argument or placeholder for every formula guarded by O operator. Hence, 
we cannot use the operator Q while writing an LTL formula. Instead we use the rule 
Previous as defined above. 

Thus, we translate the rules in the specification to a set of definition of eval and 
update operators. Once we have this translation we can easily execute, or in other words, 
evaluate all the monitors at each state in a trace of a running program. 
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We have an implementation for the monitoring framework for EAGLE in Java. The 
implemented system works in two phases. First, it compiles the specification file to 
synthesize a set of Java classes; a class is generated for each rule. Second, the Java class 
files are compiled into Java bytecode and then the monitoring engine dynamically loads 
the Java classes for rules at monitoring time and monitors a trace. 

However, for the purpose of LTL monitoring we do not have to synthesize the Java 
classes as the set of rules are fixed. Rather, we hardwire the whole algorithm in the 
implementation. 

In order to make the implementation efficient we use the decision procedure of 
Hsiang [13]. The procedure reduces a tautological formula to the constant true, a false 
formula to the constant false, and all other formulas to canonical forms which are ex- 
clusive disjunction (©) of conjunctions. The procedure is given below using equations 
that are shown to be Church-Rosser and terminating modulo associativity and commu- 
tativity. 


true A <t> = <j> 

<j)A<j> = <j> 

<j> © <)> = false 

<j>X A (<j ) 2 ® (>3) = (<})l A <J) 2 ) © ( 4 >l A < 1 > 3 ) 
<j>X -»• <j>2 = true®<j>i ®(<j>i A <(>2) 


false A (j) = false 
false ® $■= <j> 

= true © u> 

<h V <j>2 = (<j>i A t)>2 ) © <l>i 0 <j>2 
<j>i = <j> 2 = true©^! © (f>2 


In particular the equations <j) A <j) = <j> and <j> © (j) = false ensures that, at the time of 
monitoring, we do not expand the formula beyond bound. The bound is given by the 
following theorem: 

Theorem 1. The size of the formula at any stage of monitoring is bounded by 
0(size(<. p).2 size ^), where <j> is the initial LTL formula for which we started monitoring. 

Proof. The above equations, when regarded as simplification rules, keeps any LTL 
formula in a canonical form, which is an exclusive disjunction of conjunctions, 
where conjuncts have temporal operators at top. Moreover, after a series of ap- 
plications of eval on the states si,S2,...,s n , the conjuncts in the normal form 
eval(. . . eval(eval(<p,si),S2) . . . ,s n ) are subterms of the initial formula (j), each having a 
temporal operator at its top. Since there are at most siz.e(f>) such subformulas, it follows 
that there are at most 2 s:ze ^ possibilities to combine them in a conjunction. The space 
requirement for each conjunct is size(§). Therefore, one needs space 0(size(i p).2 s,ze ^) 
to store any exclusive disjunction of such conjunctions. □ 

The implementation contains a strategy for the application of these equations that en- 
sures that the time complexity of each step in monitoring is 0(size 2 (§) .2 2 ' s ‘ z *^l). We 
next describe the strategy briefly. Since, our LTL formulas are exclusive disjunction of 
conjunctions we can treat them as a tree of depth two: the root node at depth 0 repre- 
senting the © operator, the children of the root at depth 1 representing the A operators, 
and the leaf nodes at depth 2 representing the temporal operators and the Java expres- 
sions. For example, figure 1 shows the tree representation of the formula p — * 0(q Ur), 
whose canonical form is true ®p © (p A 0(q U r)). 
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Fig. 1. Tree representation of p —* 0(? 'll r) 


When we apply eval on a formula and a state the eval function is applied in depth- 
first fashion on this tree and we build up the resultant formula in a bottom-up fashion. 
At the leaves the application of eval results either in the evaluation of a Java expression 
or the evaluation of a rule. The evaluation of a Java expression returns either true or 
false. We assume that this evaluation takes unit time. On the other-hand, the evaluation 
of a rule may result in an another formula in canonical form. The formula at any internal 
node is. then evaluated by taking the conjunction (or exclusive disjunction) of the for- 
mulas of the children nodes as they get evaluated. The following gives the pseudocode 
for the startegy: 

Form eval(F,s ) 

begin ; 

Form F 1 ; 

if F is con junction of subformulas then 
F' = true ; 

for each subformula Fsub of F do 
F' = F 1 A eval(Fsub,s); 
endfor 

else if F is exclusive disjunction of subformulas then 
F' = false ; 

for each subformula Fsub of F do 
F’ = F' © eval(Fsub,s ); 
endfor 

else if A is a rule or expression then 

endif 
return F' ; 
endsub 
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Note that the application of conjunction on two formulas in canonical form requires 
the application of the distributive equation (jq A (tf>2 ® (fo) = (<j>i A tib) ® (<j)i A <(> 3 ) and 
possibly other equations. 

At any stage of this algorithm there are three formulas that are active: the orig- 
inal formula F on which eval is applied, the formula F' , and the result of the eval- 
uation of the subformula Fsub. So, by theorem 1 we can say that the space com- 
plexity of this algorithm is 0{size(^).2 size ^). Moreover, the algorithm traverses the 
formula once at each node it can possibly spend 0(size(§) .2 s ‘ ze W) time to do the 
conjunction and exclusive disjunction. Hence the time complexity of the algorithm 
is 0(size(§).2 me ^).0(size(<b).2 size ^) or 0(size 2 (cj>). 2 2 ' s,ze ^). These two bounds are 
given as the following theorem. 

Theorem 2. At any stage of monitoring the space and time complexity of the eval- 
uation of the monitored LTL formula on the current state is 0(size{if).2' size ^) and 
0(size 2 (( fj.2 2 - size ^ ) respectively. 

Eagle has been applied to test a planetary rover controller in a collaborative effort 
with other colleagues, see [2] for an earlier similar experiment using a simpler logic. 
The rover controller, written in 35,000 lines of C++, executes action plans. The testing 
environment, consists of a test-case generator, automatically generating input plans for 
the controller. Additionally, for each input plan a set of temporal formulas is generated 
that the plan execution should satisfy. The controller is executed on the generated plans 
and the implementation of Eagle is used to monitor that execution traces satisfy the 
formulas. A previously unknown error was detected in the first run, demonstrating that 
a certain task did not.recognize the too early termination of some other task. 

5 Conclusion and Future Work 

We have presented a representation of linear temporal logic with both past and future 
temporal operators in Eagle. We have shown how the generalized monitoring algo- 
rithm for EAGLE becomes simple and elegant for this particular case. We have bounded 
the space and time complexity of this specialized algorithm and thus showed that gen- 
eral LTL monitoring is efficient if we use EAGLE framework. Initial experiments have 
been successful. Future work includes: optimizing the current implementation; investi- 
gating other efficient subsets of Eagle and associating actions with formulas. 
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